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An Echoing Strategy For Satellite Links 
I. Introduction 


As mentioned in RFC 346 ("Satellite Considerations" by Jon Postel) 
those interactive systems which provide echoing for full-duplex 
terminals over the ARPANET become more awkward to use as transmission 
delays increase. The reason, of course, is that a character’s round 
trip time is added to the inherent echo delay of the server with the 
result that the terminal echoing appears extremely sluggish. 


For a terminal separated from its server by a single satellite link, 
the delay will be such that even if echoing at the server were 
instantaneous, the latency between keying and printing of an input 
character will be nearly half a second. If, in addition, the 
character is routed thru a portion of the surface net, the delay will 
be of course increase. It is estimated that echo delays of at least 
one second will not be uncommon. 


This document describes a strategy which will eliminate the delay 
associated with simple echoing and allow the transmission delay to be 
hidden in the cost of computation only. This scheme is proposed as 
an optional addition to existing User TELNETs; its use requires the 
explicit support of a cooperating server process. 


II. Standard Echo Strategy 


Echoing for locally connected full-duplex terminals is normally 
provided at the server by a resident system task called the (e.g.) 
Terminal Handler. The Terminal Handler echoes on a one-for-one or 
simple replacement basis and buffers all typed input on behalf of the 
user process. 


To let the user process operate most efficiently, the Terminal 
Handler should collect characters until a complete command or 
parameter (or whatever) has been typed. Then, presumably, the 
process can do some significant computing. Since the user process 
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knows the syntax of the string it expects, it can specify to the 
Terminal Handler those characters which delimit completed parameters. 
Such characters are called ’Wakeup Characters’ since the user process 
is awakened as they are echoed. 


Certain commands keyed by the user will require an output response 
from the process. In order that the typed commands be followed by 
its response and be separated from succeeding commands, the Terminal 
Handler must suspend echoing of user type-ahead. It can resume 
echoing (starting for type-ahead - with the unechoed characters in 
the buffer) as soon as the process has stated (implicitly or 
explicitly) that it has completed the output response. 


Characters which cause the Terminal Handler to suspend echoing are 
called ‘break characters’ They are specified by the user process 
based upon the syntax of the expected input. Normally break 
characters are also wakeup characters. As examples: 


1. A text editor may gobble up typed English sentences every time 
a period or question mark is echoed. The two characters are 
wakeup characters only. There is no need to suspend echoing. 


2. In some systems, an ESC character is used to invoke command 
recognition. The user who types 


CO [ESC] ABC [ESC] XYZ 
should see as output 
COPY (FROM FILE) ABC (TO FILE) XYZ 


The ESC is both a break and a wakeup. The printout should be 
the same no matter how fast the user types. 


The server must provide a means for each user process to communicate 
the following to the Terminal Handler: 


1. the set of wakeup characters, 

2. the set of break characters, 

3. which break characters should and which should not be echoed, 

(Some break characters - such as ESC in example 2 - should not 

be echoed). 

completion of an output response, 

5. whether or not to echo characters. (Not echoing is useful in 
"hide your input" applications.) 


A 
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As far as implementation, 1. and 2. could be communicated by allowing 
the user process to specify a 128-bit (for an ASCII device) table 
with 1’s set for each wakeup character, and another table with 1’s 
set for each break character. This approach becomes fairly expensive 
in terms of core memory as the number of terminals becomes large; the 
system must store these bit tables itself since in most cases the 
user process will not be in core while echoing is being done by the 
Terminal Handler. 


To reduce the storage requirements, the system can make known to all 
its programmers a limited number, say 4, of supported break 
characters for his process from, for example: 


a. alphanumeric characters, 

b. punctuation characters, 

c. echoable control characters (including the bell and CR, etc.), 
or 

d. non-echoable control characters (Control-C, etc.), 


by specifying in a system call which break set(s) should be used. 
This requires no more than 4 bits of system storage per terminal, and 
a single table to identify the set(s) to which each of the 128 
possible ASCII characters belongs. 


For the user process to communicate (3) to the Terminal Handler 
(which break characters should and which should not have echoed), the 
process can specify another 4 bit field with 1’s set for those break 
classes whose members should be echoed. For the 4 classes above, 
only 3 bits would be required since members of class (d) are defined 
to be non-echoable. 


To communicate the completion of an output response (4), the user 
process could issue an explicit system call; or, the Terminal Handler 
could assume completion when the user process requests input of the 
first character following the break. 


"Hide your input" (5) would be communicated by a system call which 
specifies either: 


(a) "break on every character and don’t echo any break characters", 
or, for example 

(b) "don’t echo anything and break on punctuation, or any control 
character" for an alphanumeric password, 


depending on the syntax of the expression to be hidden. 
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III. Definitions 


Several new terms need to be defined, some of which are direct 
extensions of the terms used in the "standard echo strategy" 
description. There is no reason to insist that the four buffers 
presented all be implemented as individual constructs; they are 
logically separated for clarity in the discussions which follow. 


Remote Controlled Echoing (RCE) 


This is the name for the echo strategy described in this document. 
Echoing will be controlled by the (remote) server but performed by 
the User TELNET. 


Input Buffer 


This is a logical buffer used by a User TELNET to hold characters 
in sequence as they are received from the terminal keyboard (after 
they have been converted to NVT characters). 


Transmission Buffer 


This is a logical buffer used by a User TELNET to hold NVT 
characters which have been typed but have not yet been transmitted 
to the server. 


Output Buffer 


This is a logical buffer used by a User TELNET to hold the NVT 
characters received from the server. 


Print Buffer 


This is a logical buffer residing in the User TELNET from which 
characters will be sent in sequence to the terminal printer. (The 
output buffer contains NVT characters which may have to be 
converted to characters employed by the actual terminal.) 


Break Classes 
The 128 possible (7-bit) ASCII characters employed by the Network 


Virtual Terminal can be partitioned into several quasi-equivalence 
classes (for example alphabetic, numeric, punctuation characters, 


etc.). These classes can be defined so that each character is a 
member of at least one class, although it may belong to more than 
one. 
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A server process may indicate to a User TELNET that certain of 
these classes (or all, or none) are to be considered break 
classes. That is, a break class is an equivalence class which is 
of special significance to the server process. In terms of the 
discussion of section II, the Server recognized 4 equivalence 
classes any combination of which might be designated as break 
class by a particular process. 


The RCE implementation will have more than 4 equivalence classes 
(perhaps as many as 8) to provide more flexibility in the choice 
of break character sets. 


Break Action 
Two break actions are possible: 


(1) a break character encountered in the input buffer IS moved to 
the print buffer at the appropriate time, or 

(2) a break character encountered in the input buffer IS NOT moved 
to the print buffer. 


The server process will specify which break action should be 
followed. (The two actions correspond to echoing or not echoing 
the break character.) 


Iv. Description 


(This description is written in terms of the TIP which, of course, 
embodies a User TELNET.) 


Remote Controlled Echoing is an attempt to remove the echo 
responsibility from the Terminal Handler and push it off into the 
TIP; wakeup processing is still handled at the server. The process’ 
interface (system calls, etc.) to the server’s Terminal Handler need 
not change, but the (abbreviated) Terminal Handler (actually a Server 
TELNET) must find a way to relay the process’ echo requirements to 
the TIP. It does this with TELNET commands and control information. 
System calls and echo parameters (break classes, etc.) peculiar to a 
particular serving Host must be interpreted by the Server Telnet 
commands. 


Character Flow 


Refer to figure 1. A character received from a full-duplex 
terminal will be converted to its NVT equivalent and placed in 
both the transmission AND the input buffers. The TIP’s 
transmission strategy determines when it will be removed from the 
transmission buffer; the server’s RCE control commands dictate 


Davidson [Page 5] 


RFC 357 An Echoing Strategy For Satellite Links June 1972 


when it will be removed from the input buffer. 


A character received from the server will be placed in the output 
buffer. 


Of the three labeled paths DISCARD, ECHO and OUTPUT, exactly one 
is enabled at all times. RCE commands dictate which one. Thus 
characters may 


(DISCARD:) be removed in sequence from the input buffer and 


discarded, 

(ECHO: ) be removed in sequence from the input buffer and 
placed in the print buffer, of 

(OUTPUT:) be removed in sequence from the output buffer and 


placed in the print buffer. 


From the print buffer they will be converted from NVT characters 
and be immediately send to the terminal’s printer. 


To +------------------- + | 
Server <----|Transmission Buffer | 
phr ntag a + | Prad From Server 
| ------------------ + 
V V 
+----------------- + 4----------------- + 
| Input Buffer | Output Buffer 
4----------------- + 4+----------------- + 
DISCARD +--ECHO---+ +---+ OUTPUT 
V V V 
To A A T SaaS F 
Oblivion Print Buffer 
+---------------------- + 


Convert from 
NVT Characters 


V 
To Terminal Printer 


Figure 1. Character Flow within the TIP 
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Server to Host 


The following are the proposed TELNET commands sent by the server 
process to the TIP. Commands (2) thru (5) should not be sent if 
RCE is not being used. 


Davidson 


(1) 


(4) 


Use Remote Controlled Echoing. The server asks the TIP to 
employ the echo strategy described in this document. The 
TIP can respond either YES (I will use it) or NO. (It is 
suggested that the response YES also be "Use RCE" to 
eliminate race conditions.) 


Set Break Action. This is actually 2 commands. The server 
can set the break action to echo or not echo a break 
character. 


Set Break Classes. This command specifies those equivalence 
classes which are to be considered break classes. It will 
be a two (8-bit) byte command. 


Note: The envisioned implementation requires the TIP to have 
a table with one entry per ASCII character. Each entry is 
formatted with one bit position for each equivalence class, 
and a bit is set or reset according as the given character 
is or is not a member of that class. The server sends a 
"Set Break Classes" command (1st byte) followed by a 
formatted control word (2nd byte) to the TIP with bit 
positions set for those equivalence classes which represent 
break classes for the server process. 


When a (virtual) character is taken from the input buffer 
the TIP does a table look-up indexed by the character. If a 
simple ANDing of the table entry with the terminal’s control 
word yields a non-zero result, a break was received. 
(Receipt of a break character enables the OUTPUT path.) 


Move to Break (MTB). This command directs the TIP to move 
characters in sequence from the input buffer to the print 
buffer until a break character is encountered. The break 
character will be moved or discarded depending on the 
previously-specified break action. (Essentially, MTB 
enables the ECHO path.) 


Delete to Break (DTB). This command directs the TIP to move 
characters in sequence from the input buffer and discard 
them until a break character is encountered. The break 
character will also be discarded. This provides a 
convenient mechanism for hiding a user’s input. (DTB 
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enables the DISCARD path.) 
Commands: User to Server 


The USER may send (via TIP) a request to the server process 
requesting that it "Use Remote Controlled Echoing" to which 
the server must respond "YES" or "NO". 


General Operation 


Very simply, the Remote Controlled Echoing strategy works as 
follows: The Server TELNET will tell the TIP to (essentially) 


echo a message, 

print the process’ response to that message, 
echo the next message 

print the response to that message 


etc., to effect an orderly listing of inputs and responses much as 
would be imposed when using a half-duplex device. 


The actual interaction depends on the control commands. When a 
terminal-serving process is invoked on behalf of a TIP user, the 
Server TELNET will send the "Use RCE" command; the TIP will 
respond "YES". Then the Server TELNET will send the "Set Break 
Action" and "Set Break Classes" commands to properly reflect the 
break strategy requested by the terminal-serving process. Lastly 
the Server TELNET will send an MTB command. This enables the ECHO 
path. 


The TIP removes characters from the input buffer and places them 
in the print buffer. When it encounters a break character, it 
performs the break action specified, and enables the OUTPUT path. 


Characters are then moved in sequence from the output buffer to 
the print buffer. When an MTB (or, DTB) is encountered, it is 
discarded and the ECHO (DISCARD) path is enabled. 


Etcetera. 
The Server TELNET may change the break action or break classes 
after an interaction, but should normally do so prior to sending 


the MTB or DTB commands. It should only send an MTB (DTB) after 
all process output from the previous message has been sent. 


Davidson [Page 8] 


RFC 357 An Echoing Strategy For Satellite Links June 1972 


Why Does This Work? 


The RCE strategy described above produces the correct result at 
the user’s terminal because it is in essence the same scheme used 
by the Terminal Handler which normally provides the echoing at the 
serving site. Initially, the characters are echoed as they are 
typed; then a break character is keyed, echoing is suspended. If 
the process produces any output response, it is printed before 
echoing of subsequent input. 


Echoing of the next command begins, if there is type-ahead, with 
the characters in the input buffer, and even if the input buffer 
is emptied immediate echoing of keyed input from the terminal is 
provided since the ECHO path remains enabled up to a break. 


Example 


(In the following, we assume all break characters are also wakeup 
characters and (carelessly) treat the two interchangeably.) 


Suppose a TIP user attempts to login to a remote server with the 
properly formatted message 


LOG NAME PASSWORD [CR] 


and that the Server TELNET has requested the use of RCE. 
Presuming that the break (and wakeup) characters sets are 
appropriately defined to include space and CR (and that the break 
action specifies they should be echoed), the primary sequence of 
RCE commands which will drive the TIP to produce the correct 
printout at the user’s terminal is: 


(1) MTB (to print "LOG "), and since the space is a break 


character, 
(2) MTB (to print "NAME "), 
(3) DTB (to delete "PASSWORD [CR]" (See section VI, number 


11)), and perhaps a message followed by 
(4) MTB (to reenable the echo path). 


We investigate in some detail how interaction at the 
process/Server TELNET interface causes these commands to be send 
to the TIP. 


When the EXEC is invoked, it issues a system call to set its break 
classes. The Server TELNET interprets the system call in terms of 
the classes supported by RCE, and sends the appropriate two-byte 
"Set Break Classes" (SBC) command to the TIP. A space is among 
the characters of the break set. 
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The EXEC asks for input, so the Server TELNET send MTB ((1) 
above). We presume the EXEC blocks until some input is available. 


The EXEC is awakened when the first space arrives; it recognizes 
the LOG command to be a call upon the LOGIN subsystem which it 
(promptly!) invokes. 


The LOGIN process issues a system call to set its break classes 
(this time both space and CR are included, and, as before, the 
Server TELNET forwards the command as an SBC). Then it asks for 
input (so the Server TELNET sends MTB ((2) above)), and blocks 
until the second space arrives. 


When the LOGIN process has verified the existence of a user with 
name NAME, it issues a system call to suppress printing of the 
next parameter (the password). In compliance, the Server TELNET 
sends DTB ((3) above). 


Once the password has been examined and verified, a message like 
[CR] [LF] LOGIN COMPLETED [CR] [LF] 


can be sent, followed by a request for input. The Server TELNET 
thus forwards an MTB ((4) above) and the sequence is completed. 


Another example 
Suppose in the above example the user had typed 
LOG NAME [CR] 


When the LOGIN process regained control, it would have noted that 
the break was a CR instead of a space. It then could have issued 


[LF] password = 


which the Server TELNET would follow (when LOGIN requests print 
suppression) with DTB. When the TIP had finished its output, the 
DISCARD path would be enabled and the user’s terminal would have 
printed: 


LOG NAME[CR] 
password = 


A 


with the cursor positioned just after the =. The TIP will hide 
the characters of the password. 
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Another Example 


Suppose a user were using a text editor, TEXT, to create a source 
file of English sentences. The TEXT subprocess might allow only 
non-formatting control characters (e.g., "Control-C") as break 
characters. The RCE strategy would allow the user to receive 
immediate echoing for all his input until he typed such a control 
character. 


V. Discussion 


The Remote Controlled Echoing Strategy is designed to provide echoing 
for a full-duplex terminal as if it were locally connected to its 
server. The effect of the long transmission delays will only be 
evident as an increase in the processing performed at a break. Only 
in the most interactive systems will such a delay be consistently 
noticeable. For example if a user invokes a long FORTRAN 
compilation, the fact that its start is delayed for half a second 
will not normally be evident. 


Furthermore, users who are able to type several messages ahead may 
only notice a processing delay as a result of the first break- 
interaction; both transmission and processing of successive messages 
may occur during the printing of "echoes" and responses to previous 
messages. 


Transmission considerations: 


In the standard echoing scheme, characters are buffered at the 
same server as they are keyed. But the user process does not see 
them until a wakeup character has been typed. This means a TIP 
using RCE could buffer characters in the transmission buffer until 
a wakeup occurs and then send off the whole bunch. Unfortunately 
we have chosen, for simplicity, to keep all knowledge of wakeup 


characters at the serving site. This means that the TIP may 
buffer beyond a wakeup (if it is not also a break) and delay the 
process from doing some useful work. However, since in this case 


no output is expected from the process, no noticeable delay is 
visible to the user, except that the next break interaction may 
take a little longer. 


If the TIP chooses to buffer input before transmission, it will 
transmit AT LEAST at every break character. The SERVER should be 
able to instruct the TIP to transmit more often if it is 
appropriate. 
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An Example: 


Conversational output LINKING is an example where transmission 
strategy is separate from the break and wakeup strategies. 
Transmission should occur on every character so that the character 
can be promptly printed at each linked terminal, but no break or 
wakeup need occur until a special escape character is typed (this 
reawakens the EXEC, for example). 


Conversational output linking also introduces another funny: 
Unsolicited Output: 


What happens when the ECHO (or DISCARD) path is enabled, but the 
input buffer is empty (i.e. immediate echoing is occurring) and 
something arrives in the output buffer? This "something" cannot be 
a response to a previously keyed command, or the ECHO path would 
be disabled. (This proof is left to the reader!) It is most likely 
a system message like 


[CR] [LF]SYSTEM WILL GO DOWN IN 5 MINUTES[CR] [LF] 
or, a character arriving from another linked terminal. 


Since such output does not fit neatly into our RCE scheme, the 
following kludge is proposed. Unsolicited output should cause the 
OUTPUT path to be enabled. The occurrence of either an MTB (DTB) 
Or Empty Output Buffer will reenable the ECHO (DISCARD) path. 


IV. Orthogonal Issues 
Several other mechanisms may reasonably be incorporated within this 


proposed addition to TELNET. The problems which need some further 
discussion include: 


1) Some means should be provided for the server to clear the 
input, transmission, print and output buffers. 

2) Some means should be provided for the user to immediately 
clear the output buffer (i.e. suppress printing of lengthy 
output). 

3) The server may want to ask about the number of characters 


remaining to be printed. 

4) A special tag character may be required to note where 
clearing of the input buffer occurred. 

5) The TIP’s transmission strategy should be specifiable by 
the server; perhaps a "Set Wakeup Classes" command should 
be implemented. 
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6) The server should be able to cause the TIP to break on the 
n-th input character regardless of whatever a break 
character has been encountered. 

7) Should the TIP or the server be responsible for properly 
echoing a formatting control character such as a TAB? 

8) The proper equivalence classes of ASCII characters have to 
be finalized. 

9) How should a CR be echoed? 

10) Should one-for-one echo replacement (e.g. "S" for ESC) or 
multi-character substitution (e.g. "^A" for Control-A) be 
provided by the TIP? 

11) The proposed DTB command directs the TIP to also discard 
the delimiting break character. Should the break character 
discard rather be dependent on setting the Break Action to 
"don’t echo" before sending the DTB? 


Several of these issues will be addressed in RFC 358. 

VII. Conclusion 
This document has presented a proposed optional addition to the User 
TELNET. The next step is to perform some simulations and to 


incorporate RCE into an experimental version of TELNET. 


No recommendation is made that the current TELNET be discarded. For 
example RCE should not be used for those half-duplex devices which 


perform their own "echoing". If RCE is adopted as an alternate means 
of echoing, changes to those TELNETs choosing not to implement it 
should be minimal. Switching from RCE to the current echo mechanism 


is an immediate result of either user or server sending a "You Echo" 
(or "ILLE Echo"). 


Much of the machinery required to implement RCE already exists at the 
interface between the server process and its Terminal Handler or 
Server TELNET. This means that no server process need be changed, 
but that the process’ means of specifying break classes, break 
actions and echoing conventions must be interpreted by the Terminal 
Handler and reissued to the TIP in terms of the corresponding RCE 
commands. 


[ This RFC was put into machine readable form for entry ] 
[ into the online RFC archives by Erik J. Verbruggen 12/97 ] 
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